Data Gap Management in a Remote Data Mirroring System

ABSTRACT

A method includes monitoring a sequence of transactions in one or more volumes. The transactions are transferred to a primary storage ( 112 ) in a given order, and are replicated to a secondary storage ( 114 ). The volumes belong to a volume group ( 204 ) for which the transactions are guaranteed to be replicated while retaining the given order. Artificial write transactions ( 228 ) are periodically issued to a protection application field, which is redefined in a given volume ( 212 ) belonging to the volume group. Records indicative of the transactions, including the artificial transactions, are stored in a disaster-proof storage unit ( 144 ). Upon verifying that a given artificial transaction has been successfully replicated in the secondary storage, the records, corresponding to the given artificial write transaction and the transactions that precede it in the sequence are deleted from the disaster-proof storage unit.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application 61/231,025, filed Aug. 4, 2009, whose disclosure is incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates generally to data protection systems, and particularly to methods and systems for protecting mirrored data against disaster events using disaster-proof storage devices.

BACKGROUND OF THE INVENTION

Various methods and systems are known in the art for protecting data in computer systems against disasters such as earthquakes, storms, floods, fires and terrorist attacks. Some solutions involve replicating (mirroring) the data in a primary and a secondary storage device.

For example, PCT International Publication WO 2006/111958 A2, whose disclosure is incorporated herein by reference, describes a method and system for data protection that includes accepting data for storage from one or more data sources. The data is sent for storage in a primary storage device and in a secondary storage device. While awaiting an indication of successful storage of the data in the secondary storage device, a record associated with the data is temporarily stored in a disaster-proof storage unit adjacent to the primary storage device. When an event damaging at least some of the data in the primary storage device occurs, the data is reconstructed using the record stored in the disaster-proof storage unit and at least part of the data stored in the secondary storage device.

SUMMARY OF THE INVENTION

An embodiment of the present invention that is described herein provides a method for data protection, including:

monitoring a sequence of transactions that modify data in one or more volumes, wherein the transactions are transferred from one or more data sources to a primary storage in a given order and are replicated to a secondary storage, and wherein the one or more volumes belong to a volume group for which the transactions are guaranteed to be replicated to the secondary storage while retaining the given order;

periodically issuing artificial write transactions to a protection application field, which is predefined in a given volume belonging to the volume group, so as to insert the artificial write transactions into the sequence;

storing respective records indicative of the transactions of the sequence, including the artificial write transactions, in a disaster-proof storage unit, in order to enable reconstruction of at least part of the data of the volume group using at least a portion of the data that is replicated in the secondary storage device and at least some of the records that are stored in the disaster-proof storage unit upon occurrence of an event that affects data storage in the primary storage; and

upon verifying that a given artificial write transaction has been successfully replicated in the secondary storage, deleting from the disaster-proof storage unit the records corresponding to the given artificial write transaction and the transactions that precede the given artificial write transaction in the sequence.

In some embodiments, verifying that the given artificial write transaction has been successfully replicated includes periodically reading the artificial write transactions from the secondary storage. In an embodiment, periodically reading the artificial write transactions includes modifying a period of time between consecutive reading operations of the artificial write transactions in real time. In another embodiment, the volume group includes a consistency group.

In a disclosed embodiment, issuing the artificial write transactions includes assigning the artificial write transactions respective unique values. In an embodiment, the unique values include serial indices. In an alternative embodiment, the unique values include time stamps. In another embodiment, verifying that the given artificial write transaction has been successfully replicated includes reading a unique value of the given artificial write transaction, and verifying that the read unique value is different from a previously-read unique value. In yet another embodiment, periodically issuing the artificial write transactions includes modifying a period of time between consecutive artificial write transactions in real time. In still another embodiment, the protection application field is included in a dedicated protection application volume that belongs to the volume group.

There is additionally provided, in accordance with an embodiment of the present invention, a data protection apparatus, including:

an interface for monitoring a sequence of transactions that modify data in one or more volumes, wherein the transactions are transferred from one or more data sources to a primary storage in a given order and are replicated to a secondary storage, and wherein the one or more volumes belong to a volume group for which the transactions are guaranteed to be replicated to the secondary storage while retaining the given order; and

a processor, which is configured to periodically issue artificial write transactions to a protection application field that is predefined in a given volume belonging to the volume group so as to insert the artificial write transactions into the sequence, to store respective records indicative of the transactions of the sequence, including the artificial write transactions, in a disaster-proof storage unit, and to delete from the disaster-proof storage unit, upon verifying that a given artificial write transaction has been successfully replicated in the secondary storage, the records corresponding to the given artificial write transaction and the transactions that precede the given artificial write transaction in the sequence.

The present invention will be more fully understood from the following detailed description of the embodiments thereof, taken together with the drawings in which:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram that schematically illustrates a data center, in accordance with an embodiment of the present invention;

FIG. 2 is a block diagram that schematically illustrates the operation of an embodiment of the present invention;

FIGS. 3A and 3B are flowcharts that schematically illustrate a method for disaster-proof storage management, in accordance with an embodiment of the present invention; and

FIG. 4 is a timing diagram that schematically illustrates a method for data gap assessment, in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS Overview

Embodiments of the present invention provide improved methods and devices for protecting data through a disaster by storing it in a Disaster-Proof temporary Storage device (DPS). A typical environment in which the disclosed techniques are embodied comprises a system, where one or more Application Servers (ASs) issue transactions that modify data in one or more Primary Storage (PS) volumes through a Storage Area Network (SAN). A typical example of such a system is a Data Center (DC). The transactions may include writing data to the PS and/or deleting data from it. The PS comprises a group of one or more volumes, either virtual or physical, designated a “volume group”, which are mirrored in a Secondary Storage (SS) device. Typically, the PS is located in a local site and the SS is located in a remote site.

A volume group is characterized by a “sequence integrity” property, meaning that for any given sequence of transactions that are applied to the volume group, the order of transactions in the PS is guaranteed to be retained in the SS. A typical example of such a volume group is a Consistency Group (CG), wherein the volumes are managed as a single entity whose secondary images always remain in a consistent and restartable state with respect to their primary image and each other, up to a defined permissible time lag. The mirroring is performed by a Replication Appliance (RA) that is connected to the SAN and constantly sends a replica of the transactions that pertain to the CG over to the SS, typically over a Wide-Area Network (WAN).

A Protection Appliance (PA) simultaneously transfers the above transactions to a DPS that is located in the local site. Typically, the content of the DPS is organized in an indexed sequential access log. The sequential order of the transactions in the log reflects the order in which those transactions have been written to the PS, which is equal to the order of their writing to the SS, as stems from the sequence integrity property.

Later, should a disaster event occur that damages the operation of the DC, thus affecting the data storage in the PS, the DPS would transmit to the SS the most recent transactions that are stored in it and are assessed to be missing in the SS. The DPS uses for this transmission an Emergency Link (EL), which sometimes comprises several communication alternatives. The recovered transactions are then merged at the SS with the transactions that have been replicated to the SS prior to the disaster event, so that the secondary CG would exactly reflect the content of the primary CG prior to the disaster event.

The PA application software constantly determines the amount of recent transactions that shall be recovered should a disaster event occur. This determination is based on an assessment of the amount of transaction data that has been already written to the PS but its writing to the SS has not been confirmed yet. This amount is herein denoted Data Gap (DG). DG is comprised, at any given moment, of the transaction data that is accumulated in the RA buffers, and of a typically small amount of data that is accumulated within the PS-to-SS link. The latter data gap component is called in this disclosure “communication DG”. The DG is approximately equal to the difference between the CG transaction data that has been synchronously applied to the PS and its corresponding asynchronous replication within the SS. Embodiments of the present invention provide methods and systems for assessing DG with high accuracy.

In many cases the remote site is planned to serve as a backup DC for the local DC, should it fails to operate. Moreover, a reliable and instant application failover between the sites is sometimes desired. A necessary condition for a reliable failover is to avoid data discrepancy between the PS and the SS, hence, the assessed DG should not be smaller than the actual DG. In addition, for providing an instant failover, the assessed DG should be as close as possible to the actual DG in order to minimize the DG recovery time. This feature is advantageous, for example, when the EL comprises a narrow bandwidth link that includes an omni-directional wireless transmission from the DPS.

In a typical embodiment of the present invention, a new protection application volume, denoted V_(PA), is added to the CG in order to assess the DG. V_(PA) instances in the PS and in the SS are denoted primary V_(PA) and secondary V_(PA) respectively. V_(PA) comprises a protection application field, which is dedicated for the purpose of accurate DG assessment. A typical embodiment comprises creation of V_(PA) through a configuration management of the data storage system. In some alternative embodiments, the PA creates the protection application field, either within one of the volumes that belong to the volume group or within a dedicated virtual volume that the PA creates.

The PA manages V_(PA) as follows: It periodically issues artificial write transactions to the V_(PA) so as to insert them into the transaction sequence that pertains to the CG. Each V_(PA) related transaction contains a record, denoted R, to which the PA assigns a respective unique value. Each record that pertains to the series R is denoted herein R as well for the simplicity. Each new record that is written to V_(PA) updates the V_(PA) protection application field, hence this field always reflects the last R unique value that the PA wrote to V_(PA). The inter-record period of R (i.e., the time interval between writing successive records R) is denoted Tw. R is written and stored within the DPS, as well as within the SS, in the same manner as the data of the other volumes that pertain to the CG.

In addition to the above writing process of R, the PA also manages a reading process wherein it constantly reads the content of the secondary V_(PA), i.e., the last R unique value that was written in the SS. Reading a new R value from the SS constitutes a confirmation for the PA that this R, as well as all the transactions that pertain to the CG and precede that R, have been already written successfully to the SS. This confirmation stems from the sequence integrity property of the CG. Consequently, the PA would delete the corresponding R from the DPS log, together with the log stored transactions that preceded it, since those transactions will not be needed for recovery. This deletion procedure limits the DPS content size to the real DG size plus an assessment error. The maximal assessment error is approximately equal to the amount of data that is written to the PS during Tw+Trt, where Trt denotes the round trip delay toward the SS. As Tw may be set as small as Trt the assessment error is approximately equal to the communication DG size.

In addition to the achieved DG assessment accuracy, the above method is a RA-independent mechanism, and therefore allows for an easy integration of a DG management and recovery system that comprises a PA and a DPS, as described above, in a DC that already comprises a mirroring system.

Embodiments of the present invention are in no way limited to data centers, and may be used in other environments, e.g. in data acquisition sites and in surveillance centers. The disclosed techniques are also applicable to storage volumes that are not necessarily arranged as CG, e.g. wherein there is no dependency between the transactions that pertain to the different volumes in the group, provided that the transaction ordering in the PS is always retained in the SS.

System Description

FIG. 1 is a block diagram that schematically illustrates a data storage system 100, in accordance with an embodiment of the present invention. System 100 comprises a local site 101 and a remote site 102, which are interconnected by a WAN 103. The illustrated WAN represents any communication means that can be used, in different example embodiments, to interconnect the above sites, e.g., an Internet Protocol (IP) network, a point to point link or a Fibre Channel based network. Local site 101 comprises a Data Center (DC) wherein one or more Application Servers (ASs) 104 issue transactions to one or more Primary Storage (PS) devices 112. Storage Area Network (SAN) 108 transfers the transactions to the storage. SAN 108 comprises, in typical embodiments of the present invention, one or more Fibre Channel switches. In alternative example embodiments, the SAN may be based on Internet Small Computer System Interface (iSCSI). Yet in other embodiments SAN 108 may represent the attachment of one or more Network Attached Storage (NAS) devices to ASs 104.

PS 112 typically comprises one or more volumes, either virtual or physical, that are arranged as a Consistency Group (CG). The CG is mirrored to a Secondary Storage (SS) 114 that is located at remote site 102. The mirroring is performed by a Replication Appliance (RA) 116 that is connected to SAN 108 and constantly sends a replica of all the transactions that pertain to the CG, over WAN 103, to a counterpart replication appliance RA 124. In some embodiments, specific replication software agents within ASs 104 generate the transactions' replica and transfer it to RA 116 through SAN 108. In alternative embodiments SAN 108 is configured to generate this replica and to provide it to RA 116 through a dedicated port. In further alternative embodiments RA 116 is not resorted to and ASs 104 communicate with remote site 102 directly. In further alternative embodiments, the replication is performed directly from PS 112 to SS 114.

Remote RA 124 is typically configured to extend the transactions coming from RA 116 over a remote SAN 128, which transfers the transactions to SS 114. A Protection Appliance (PA) 140 simultaneously receives yet another replica of the CG related transactions. PA 140 comprises an interface 141 for communicating with SAN 108. PA 140 also comprises a processor 142 which executes the logical operations of the PA. PA 140 directly transfers the above transactions to a Disaster-Proof Storage device (DPS) 144. In an alternative embodiment, PA 140 communicates with DPS 144 via SAN 108 and interface 141. The DPS is configured to store the transactions that PA 140 writes to it in a log that is organized in indexed sequential access manner. The sequential order of the transactions in the log reflects the order in which those transactions have been written to PS 112, which is equal to the order of their writing to SS 114, as stems from the sequence integrity property of CGs.

DPS 144 is configured to sense a major failure of local site 101, which may happen through a disaster event and would affect the data storage in the PS. Should such failure occur DPS 144 would transmit to SS 114 the most recent transactions that are stored in it and are assessed to be missing in the SS. DPS 144 uses for this transmission an Emergency Link (EL) 148, which typically comprises several communication alternatives. In typical embodiments, one of these alternatives would be an omni-directional wireless transmission. EL 148 passes the recovered transactions to a counterpart PA 152 at the remote site, which applies them to SS 114 through SAN 128, either directly or via RA 124. The recovered transactions complement the transactions that were replicated to the SS prior to the disaster event, so that the secondary CG would exactly reflect the content of the primary CG prior to the disaster event.

In some embodiments, the remote site comprises another DPS 156, e.g., when site 102 operates as an active DC that comprises optional ASs 136, such that storage 112 serves as a mirroring medium for storage 114. Should the DC in site 102 fail due to a disaster event, DPS 156 would recover the transactions to storage 114 that are missing in storage 112 through an EL 160.

The configuration of system 100 shown in FIG. 1 is an example configuration, which is chosen purely for the sake of conceptual clarity. PS 112 and SS 114 may comprise any suitable type of storage device, such as magnetic disks or solid-state memory units. System elements that are not mandatory for understanding the disclosed techniques were omitted from the figure for the sake of clarity. In alternative embodiments, other system configurations can also be used. For example, RA 116 may write to SS 114 via WAN 103 and SAN 128, without the mediation of RA 124. In other alternative embodiments PS 112 may comprise multiple CGs that may be mirrored to SS 114 or to multiple remote sites.

In some embodiments, the functions of PA 140 are implemented in software running on a suitable processor. In alternative embodiments, some or all of the functions of PA 140 can be implemented in hardware, or using a combination of hardware and software elements. In some embodiments, PA 140 comprises a general-purpose computer, which is programmed in software to carry out the functions described herein. The software may be downloaded to the computer in electronic form, over a network, for example, or it may, alternatively or additionally, be provided and/or stored on non-transitory tangible media, such as magnetic, optical, or electronic memory. Further aspects regarding the operation of PA 140, and data storage using disaster-proof storage devices in general, are addressed in PCT International Publication WO 2006/111958, cited above.

Logical System Operation

FIG. 2 is a block diagram that schematically illustrates the operation principles of an embodiment of the present invention. A group of virtual volumes V₁₋₁,d V₂₋₁, . . . V_(k−1) and V_(PA-1) 212 constitutes a CG whose primary instance is denoted CG 204 and is stored in PS 112. RA 116 constantly replicates CG 204 to remote site 102 through WAN 103. Within the remote site, RA 124 receives the replicated transactions that pertain to the CG and copies them to virtual volumes V₁₋₂, V₂₋₂, . . . V_(k-2) and V_(PA-2) 216 respectively, thus forming a mirrored CG 208 in SS 114. V_(PA), which is the general notation of V_(PA-1) and Vp_(PA-2), comprises a single record, which PA 140 manages as follows:

PA 140 generates a periodical series of serially indexed records, denoted R 218, and writes it in a series of transactions V_(PA) 220 to V_(PA-1) 212. For the sake of simplicity, R 218 denotes the series of records as well as each separate record that pertains to this series. The main content of record R is its running index. As W_(PA) comprises a single record, each new W_(PA) 220 tramples the previously stored one. Immediately after writing V_(PA) 220 to V_(PA-1) 212, PA 140 receives a replica of W_(PA) 220, as explained above, and writes it as W_(PA) 224 to DPS 144. RA 116 receives a replica of W_(PA) 220 as well, and combines it as W_(PA) 228 within a transaction sequence . . . W-n, W-n+1, . . . W_(PA), . . . W0 that it replicates to remote site 102 over WAN 103. In this sequence, all the transactions that have been written to CG 204 prior to W_(PA) 228 will be replicated to CG 208 prior to W_(PA) 228 as well, as stems from the sequence integrity property of CGs. RA 124 receives the above record sequence and copies it to CG 208. In particularly it writes W_(PA) 232 record series to V_(PA-2) within CG 208. PA 140 also manages, within DPS 144, a sequential list 234 that contains the R records that it has recently written to the DPS. Each list 234 entry contains also a pointer to the corresponding R record in the log.

Concurrently with the above writing process of W_(PA), PA 140 is configured to constantly read, typically over WAN 103, the content of V_(PA-2) 216, in a read transaction R_(PA) 236. PA 140 receives R_(PA) 236 through the WAN as R_(PA) 240 and checks its index. Upon reading a new R_(PA) index, PA 140 deletes the following data that is stored in DPS 144: The corresponding entry in list 234, the W_(PA) entry that it has pointed in the log and all the log entries that have preceded that W_(PA). PA 140 can safely delete the above data due to the fact that replication of that data to CG 208 has been actually confirmed by the above new R_(PA) index.

The deletion would leave in DPS 144 only the necessary transactions for recovery, should a disaster event occur, thus shortening later recovery time through EL 148. This amount of transactions is an assessment of the difference, at any given moment, between CG 204 and CG 208, which is called “Data Gap” (DG). In alternative embodiments, DPS 144 is arranged to manage list 234 and the above deletion process according to information regarding new R_(PA) 240 indices, which PA 140 constantly conveys to DPS 144.

DG Assessment MEthod

FIG. 3A is a flowchart that schematically illustrates the writing part of a method for DG assessment and for managing DPS 144 content, in accordance with an embodiment of the present invention. The method begins by adding a virtual volume V_(PA) to a consistency group CG, at an adding V_(PA) step 304. This adding step demonstrates an option to integrate the disclosed techniques into an existing DC. In other embodiments of the present invention, wherein a mirrored CG comprises V_(PA) when it is established, step 304 may be redundant. In a W_(PA) writing step 308, PA 140 writes a serially indexed record R in transaction W_(PA) 220 to V_(PA-1) 212. DPS 144 receives a replica of W_(PA) 220, denoted W_(PA) 224. RA 124 writes a second replica of W_(PA) 220, denoted W_(PA) 232, to secondary V_(PA-2) 216. In a wait Tw step 312, PA 140 waits a period Tw 314 and resumes step 308, thus forming a series of transactions W_(PA).

FIG. 3B is a flowchart that schematically illustrates the reading part of a method for DG assessment and for managing DPS 144 content, in accordance with an embodiment of the present invention. This part of the method begins with a read R_(PA) 316 step, wherein local PA 140 issues a read transaction, denoted R_(PA), for checking the actual V_(PA-2) index at remote CG 208. PA 140 waits for the arrival of the read index in a wait Trt step 324, wherein Trt denotes the round trip delay of the R_(PA) read transaction. PA 140 is configured to make the following decision, in a decision step 328, according the received R_(PA) index: If the index value has not been changed relative to the previous read index then PA 140 would resume step 316. If the index value is a new one, then PA 140 assumes a deletion step 332. In deletion step 332 PA 140 deletes all DPS 144 log transactions that precede the stored W_(PA), whose index is the same as the newly read index, including that W_(PA). PA 140 resumes step 316 after the deletion.

FIG. 4 is a timing diagram that schematically illustrates a method for DG assessment, in accordance with an embodiment of the present invention. A time axis 404 illustrates V_(PA) related events that occur over time in PA 140. PA 140 issues transactions W_(PA1), W_(PA2), . . . to V_(PA-2) 216 with inter-transaction period Tw 314. Tw 314 is set as twice the value of the round trip delay toward SS 114, denoted Trt 324. In alternative embodiments, Tw may be set as small as Trt for minimizing the DG assessment error to the communication DG size over the WAN. PA 140 concurrently issues read transactions from V_(PA-2) 216 with inter-transaction period Trt 314.

In FIG. 4 those transactions are illustrated in terms of the actual V_(PA-2) record indices that PA 140 reads. These indices are denoted R₀, R₁, . . . R₄ on a time axis 408. PA 140 receives each read index Trt seconds after the issuance of the read transaction. The read indices are denoted on time axis 404, wherein indices that are not new are omitted. In alternative embodiments, PA 140 software identifies the W_(PA) records with timestamps instead of running indices.

PA 140 managing the transaction log within DPS 144 is exemplified in the following example: PA 140 issues in a time t_(w3) 412 a transaction W_(PA3). PA 140 receives W_(PA3)′s index R3 the first time at a time instance t_(R3) 416. PA 140 then deletes all the transactions that have been stored in DPS 144 log before W_(PA3), including W_(PA3) itself. This deletion action is illustrated in FIG. 4 by a double arrow 420. In alternative embodiments, indices R3 are substituted by time stamps or using any other suitable type of unique values that assigned to the artificial write transactions. Yet in other alternative embodiments, the read transaction period is adjusted to be larger than Trt in order to save overhead throughput over WAN 103. On the other hand, the inter-transaction periods of W_(PA) 220 and R_(PA) 236 are typically limited in order to minimize the DG assessment error.

In further alternative embodiments, PA 140 adjusts, in real time, the W_(PA) 220 and R_(PA) 236 inter-transaction periods as follows: The PA limits the overall W_(PA) and R_(PA) throughput so as to ensure a minimal impact on the actual replication throughput through WAN 103. In addition, the PA limits Tw 314 magnitude so that at any given moment the actual total writing amount to CG 204 during Tw would be much smaller than the overall content size within DPS 144. Yet in further alternative embodiments of the present invention PA 140 may set, either in software or in hardware or in a combination thereof, any other suitable combination of W_(PA) 220 and R_(PA) 236 inter-transaction periods. These combinations may rely on predetermined values of relevant factors like Trt, overall writing throughput to CG 204 and the effective throughput through WAN 103. These values may alternatively be determined in real time, and affect the chosen combination accordingly.

Although in the embodiments described herein the DG assessment and DPS management mechanism is implemented externally to RAs 116 and 124, they can alternatively be implemented within the RAs thus saving separate PAs 140 and 152.

It will thus be appreciated that the embodiments described above are cited by way of example, and that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and sub-combinations of the various features described hereinabove, as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art. 

1. A method for data protection, comprising: monitoring a sequence of transactions that modify data in one or more volumes, wherein the transactions are transferred from one or more data sources to a primary storage in a given order and are replicated to a secondary storage, and wherein the one or more volumes belong to a volume group for which the transactions are guaranteed to be replicated to the secondary storage while retaining the given order; periodically issuing artificial write transactions to a protection application field, which is predefined in a given volume belonging to the volume group, so as to insert the artificial write transactions into the sequence; storing respective records indicative of the transactions of the sequence, including the artificial write transactions, in a disaster-proof storage unit, in order to enable reconstruction of at least part of the data of the volume group using at least a portion of the data that is replicated in the secondary storage device and at least some of the records that are stored in the disaster-proof storage unit upon occurrence of an event that affects data storage in the primary storage; and upon verifying that a given artificial write transaction has been successfully replicated in the secondary storage, deleting from the disaster-proof storage unit the records corresponding to the given artificial write transaction and the transactions that precede the given artificial write transaction in the sequence.
 2. The method according to claim 1, wherein verifying that the given artificial write transaction has been successfully replicated comprises periodically reading the artificial write transactions from the secondary storage.
 3. The method according to claim 2, wherein periodically reading the artificial write transactions comprises modifying a period of time between consecutive reading operations of the artificial write transactions in real time.
 4. The method according to claim 1, wherein the volume group comprises a consistency group.
 5. The method according to claim 1, wherein issuing the artificial write transactions comprises assigning the artificial write transactions respective unique values.
 6. The method according to claim 5, wherein the unique values comprise serial indices.
 7. The method according to claim 5, wherein the unique values comprise time stamps.
 8. The method according to claim 5, wherein verifying that the given artificial write transaction has been successfully replicated comprises reading a unique value of the given artificial write transaction, and verifying that the read unique value is different from a previously-read unique value.
 9. The method according to claim 1, wherein periodically issuing the artificial write transactions comprises modifying a period of time between consecutive artificial write transactions in real time.
 10. The method according to claim 1, wherein the protection application field is comprised in a dedicated protection application volume that belongs to the volume group.
 11. A data protection apparatus, comprising: an interface for monitoring a sequence of transactions that modify data in one or more volumes, wherein the transactions are transferred from one or more data sources to a primary storage in a given order and are replicated to a secondary storage, and wherein the one or more volumes belong to a volume group for which the transactions are guaranteed to be replicated to the secondary storage while retaining the given order; and a processor, which is configured to periodically issue artificial write transactions to a protection application field that is predefined in a given volume belonging to the volume group so as to insert the artificial write transactions into the sequence, to store respective records indicative of the transactions of the sequence, including the artificial write transactions, in a disaster-proof storage unit, and to delete from the disaster-proof storage unit, upon verifying that a given artificial write transaction has been successfully replicated in the secondary storage, the records corresponding to the given artificial write transaction and the transactions that precede the given artificial write transaction in the sequence.
 12. The apparatus according to claim 11, wherein the processor is configured to verify that the given artificial write transaction has been successfully replicated by periodically reading the artificial write transactions from the secondary storage.
 13. The apparatus according to claim 12, wherein the processor is configured to modify a period of time between consecutive reading operations of the artificial write transactions in real time.
 14. The apparatus according to claim 11, 0wherein the volume group comprises a consistency group.
 15. The apparatus according to claim 11, wherein the processor is configured to assign the artificial write transactions respective unique values.
 16. The apparatus according to claim 15, wherein the unique values comprise serial indices.
 17. The apparatus according to claim 15, wherein the unique values comprise time stamps.
 18. The apparatus according to claim 15, wherein the processor is configured to verify that the given artificial write transaction has been successfully replicated by reading a unique value of the given artificial write transaction, and verifying that the read unique value is different from a previously-read unique value.
 19. The apparatus according to claim 11, wherein the processor is configured to modify a period of time between consecutive artificial write transactions in real time.
 20. The apparatus according to claim 11, wherein the protection application field is comprised in a dedicated protection application volume that belongs to the volume group.
 21. The apparatus according to claim 11, wherein the processor is configured to create the protection application field prior to issuing the artificial write transactions.
 22. The apparatus according to claim 11, wherein the processor is configured to create a protection application volume, which belongs to the volume group and comprises the protection application field, prior to issuing the artificial write transactions. 